--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Ray,
>  
> That sounds like a good idea.  It it works out for you I would like to add that to the code base.  Maybe we should have a configuration number in the Tool Setup to define a bit (normally Virtual) for that purpose.   Regarding the tool changes and so forth we could add a second status bit that would be set whenever an M code invoked C program is running in the Execute+Wait modes.  You of course also always have the option to set/clear any bit within any individual C program.
>  
> Regarding Jog during a tool change or any M code - there is a Execute+Wait+Sync option for M codes. This means that the Interpreter state will sync to the final tool position after the M code finishes.  So for example if the operator jogged to position xy=2,2 and then the next Gcode was G1 X3 Y3.  Then the machine would move properly from 2,2 to 3,3 in a straight line.  Its not clear if that's what you mean or if you are expecting it to move back to where it was before the jog or something.
>  
> You can not Jog while in FeedHold.  From KFLOPs perspective it is no different from just feeding really really slow.  From a internal software perspective FeedHold/Resume is relatively simple.  Halt/Resume is extremely complex.  It does a feedhold first and then Halts the Coordinated motion buffer and Interpreter and rewinds everything backwards through the buffering and Trajectory Planner to put everything in the proper state for a Resume most likely mid-way through an GCode that might be in the middle of multiple tool compensated arcs and whatnot.   And the Resume may be after changes in offsets and jogs.  But I find Users never use the FeedHold.  They typically halt/resume even though they really don't need to.  There is an advantage to feedhold if triggered by an external switch connected directly to KFLOP as it is guaranteed to be instant.  Where a screen button under MS Windows will only be instant 99% of the time.
>  
> HTH
> TK
>  
>
> From: himykabibble <jagboy@...>
> To: DynoMotion@yahoogroups.com
> Sent: Sunday, January 8, 2012 4:21 PM
> Subject: [DynoMotion] Re: Performing FeedHold
>
>
>  
> Tom,
>
> OK, thanks. Next question - We talked a while ago about providing some means to block jogging when a program was running. What I'm thinking of doing is setting a pin active when I kick off the interpreter, and clear it when the interpreter stops for any reason - FeedHold, Stop, ProgramEnd, etc. My jog code on the DSP will then look at that pin, and do nothing if the pin is active. Does that sound like a viable approach?
>
> The one thing I'm not clear on, is how to handle toolchanges and M1s. When a toolchange or M1 occurs, I NEED to be able to jog, sometimes probe, maybe some other things. But I see no way to know that the Interpreter is in a state where jogging and other operations SHOULD be allowed. Any ideas? And if I jog during a toolchange, will the interpreter resume properly? If not, then the only option I can see would be to parse the code myself, and call the Interpreter to execute only up to each toolchange, then return control to my app. After the toolchange was complete, I'd then turn control back over to the Interpreter. I REALLY hope I don't need to do anything like that...
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> >
> > Hi Ray,
> >  
> > That is correct.  But the Interpreter can also do "Independent" moves for Rapids (G0).  The feedhold also works/applies to those.  Any independent motion of any axis that is included in the Coordinate System, if moving independently, will also be stopped by basically issuing a Jog(xx,0.0), the original destination will be saved, and if the feedhold is resumed a new independent Move to the original destination will be initiated.  So the application should be able to do feedhold/resumes regardless of what was causing the motion.
> >  
> > Regards
> > TK 
> >
> > From: himykabibble <jagboy@>
> > To: DynoMotion@yahoogroups.com
> > Sent: Sunday, January 8, 2012 10:12 AM
> > Subject: [DynoMotion] Re: Performing FeedHold
> >
> >
> >  
> > Tom,
> >
> > OK, that makes more sense. You might want to clarify that in the docs - My read was Clear "turned off" feedhold, as in resumed motion. I never would've guessed it worked as you just described (which makes more sense). So sounds like that might be a good to do as part of a "Stop", just to ensure a consistent state, no?
> >
> > If my understanding is corect:
> >
> > If running, User presses the FeedHold toggle button, and StopState == "0", I should issue a "StopImmediate0" to pause the motion. If StopState != "0", then I should issue a "StopImmediate1", to resume motion. If, after stopping, the user wants to just abort the motion entirely (by pressing the Stop button), rather than resume, I should issue a "StopImmediate2" to cancel the move that was paused. Is that correct?
> >
> > Am I correct in thinking that the Interpreter will do only CoordMotion calls, and that single axis moves can come only from jogging and other manually initiated operations (i.e. - pendant/jog code, probes, homes, etc.)?
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > >
> > > Hi Ray,
> > >  
> > > Feedhold Resume (1) and Clear (0) are totally different.  Feedhold is essentially accomplished by reducing the rate of "Time" to zero.  So for example if we are contouring a circle and we command a feedhold (0) the feedrate is essentually reduced to zero but as far as everything (the coordinated motion buffer, the Interpreter, Mach3 or KMotionCNC, and so forth) we are still in progress of doing the circle.  Resume (1) simply ramps the rate of "Time" back to normal so the motion continues on.  Clear (2) is used when we wish to abort the coordinated motion.  It exits KFLOP from coordinated motion mode and returns to idle mode which essentially flushes the remainder of the coordinated motion buffer.
> > >  
> > > Sorry if it was a poor choice of terms.
> > >  
> > > TK
> > >
> > > From: himykabibble <jagboy@>
> > > To: DynoMotion@yahoogroups.com
> > > Sent: Saturday, January 7, 2012 6:13 PM
> > > Subject: [DynoMotion] Performing FeedHold
> > >
> > >
> > >  
> > > I'm trying to sort out the logic for FeedHold, and finding looking at the KMotionCNC code and the documentation rather confusing. The FeedHold button handler in KMotionCNC does the following:
> > >
> > > CString response;
> > > if (TheFrame->KMotionDLL.WriteLineReadLine(board,"GetStopState",response.GetBufferSetLength(MAX_LINE))) return;
> > > response.ReleaseBuffer();
> > > if (response=="0")
> > > {
> > > TheFrame->KMotionDLL.WriteLine(board,"StopImmediate0");
> > > }
> > > else
> > > {
> > > TheFrame->KMotionDLL.WriteLine(board,"StopImmediate1");
> > > }
> > >
> > > The three StopImmediate modes are documented as:
> > >
> > > 0 - Stops the axes motion (equivalent to User C Program function StopCoordinatedMotion)
> > > 1 - Resumes the axes motion (equivalent to User C Program function ResumeCoordinatedMotion)
> > > 2 - Clears the Feed hold state (equivalent to User C Program function ClearStopImmediately)
> > >
> > > So, the FeedHold code does not actually use the feature that supposedly clears the FeedHold state. Why? And if this clears FeedHold, what *sets* FeedHold? What is the difference between modes 1 and 2?
> > >
> > > Regards,
> > > Ray L.
> > >
> >
>